Over the last decade, malicious software has become a pervasive problem for Internet users as many networked resources include vulnerabilities that are subject to attack. For instance, over the past few years, more and more vulnerabilities are being discovered in software that is loaded onto network devices, such as vulnerabilities within operating systems for example. While some vulnerabilities continue to be addressed through software patches, prior to the release of such software patches, network devices will continue to be targeted for attack by malware, namely information such as computer code that attempts during execution to take advantage of a vulnerability in computer software by acquiring sensitive information or adversely influencing or attacking normal operations of the network device or the entire enterprise network.
For example, one commonly exploited vulnerability is known as a buffer overflow. In general, programs write data to a buffer. However, during a buffer overflow, the written data overruns the buffer's allocated boundary and overwrites adjacent memory locations. As a result, buffer overflows are the basis of many software vulnerabilities and can be maliciously exploited to cause erratic program behavior, memory access errors, incorrect results, and/or the misappropriation of sensitive data such as intellectual property.
Various techniques have been attempted to detect and prevent software exploits, however each technique has various tradeoffs. One of the most generic techniques include Data Execution Prevention (DEP), which is generally provided for by a processor. Using DEP, memory spaces are automatically marked as non-executable unless they are explicitly told they are being allocated for executable code. Specifically, a flag is set on a per-page basis and is set via a bit in the page table entry (PTE) for that page. If an attempt is made to execute code from a memory region that is marked as non-executable, the hardware feature passes an exception to DEP within the operating system and provides a corresponding indication. Consequently, DEP causes an exception within the code stack that is executing, thereby causing a failure coupled with an access violation. DEP may be made stronger by CPU support with the No-Execute (NX) bit, also known as the XD bit, EVP bit, or XN bit, which allows the CPU to enforce execution rights at the hardware level.
Unfortunately, in short order, bypasses were developed by hackers to overcome DEP schemes. Specifically, a technique known as Return-Oriented Programming (ROP) was developed to circumvent DEP schemes. ROP techniques search for portions of code known as ROP gadgets in legitimate modules within a particular process. ROP gadgets generally comprise of one or more instructions, followed by a return. Combining a plurality of ROP gadgets along with appropriate values in the stack allows for the malicious shell code to be executed. Typically, the hacker's goal is to locate the address of a memory protection API, such as VirtualProtect, and mark the relevant memory region as executable (as compared to non-executable). Thereafter, the hacker may introduce a final ROP gadget to transfer the execution to the relevant memory region to execute the shellcode. As a result, the DEP scheme may be bypassed.
In an effort to make potential DEP bypasses more difficult, Address Space Layout Randomization (ASLR) was developed. ASLR involves randomly offsetting memory structures and module base addresses such that merely “guessing” the location of ROP gadgets and APIs becomes exceedingly difficult. On certain operating systems, such as the Microsoft® Windows® operating system, ASLR may be configured to randomize the location of executables and Dynamic Link Libraries (DLLs) in memory, stacks and heaps. For example, when an executable is loaded into memory, the operating system may receive a processor's timestamp counter (TSC), shift the TSC by a nominal amount, perform a division (e.g., a modulo operation), and then add a constant. The result of this operation may then be multiplied by yet another constant, at which point an executable image is loaded at the calculated offset.
However, some DLLs (including for example, ntdll, kernel32, etc.) are shared in memory across processes, their offsets are determined by a system-wide bias value that is computed at boot. Notably, the offset value is computed only once per boot. When DLLs are loaded, they are disposed into a shared memory region. The order in which modules are loaded is randomized too. Furthermore, when threads are created, their stack base address is randomized. Once the base address has been calculated, another value is derived from the TSC to compute the final stack base address. By using this method, ASLR was intended to provide a high theoretical degree of randomness.
When all of these ALSR mechanisms were combined with DEP, it was understood that shellcode would be prevented from executing because the memory region could not be executed. Moreover, it was expected that potential hackers also would not know the location of any ROP instructions in memory because the ROP gadget's address would be unreliable due to the randomization.
Nonetheless, bypasses were developed by hackers to overcome ASLR mechanisms so that DEP schemes could be easily exploited. For example, NOP sleds may be utilized to create a probabilistic exploit. Furthermore, using a pointer leak, a hacker can make an educated guess regarding a value on the stack at a reliable location to locate a usable function pointer or ROP gadget.
In other words, using these and other techniques, it may be possible to create a payload that reliably bypasses both DEP and ASLR. Moreover, once ASLR and DEP are compromised, it is a straight forward matter to control the execution of shellcode in the context of the application. Therefore, there exists a need for a system, apparatus and method for identifying potential application-execution hijacking attacks using memory protection techniques so as to prevent the execution of malicious shellcode.